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ABSTRACT 


The current Life Sciences Laboratory Equipment (LSLE) microcomputer for 
life sciences experiment data acquisition is now obsolete. Among the 
weaknesses of the current microcomputer are small memory size, relatively 
slow analog data sampling rates, and the lack of a bulk data storage device. 
While life science investigators normally prefer data to be transmitted to 
Earth as it is taken, this is not always possible. No down-link exists for 
experiments performed in the Shuttle middeck region. One important aspect 
of a replacement microcomputer is provision for in-flight storage of 
experimental data. 


The Write Once, Read Many (WORM) optical disk was studied because of its 
high storage density, data integrity, and the availability of a space-qualified 
unit. In keeping with the goals for a replacement microcomputer based 
upon commercially available components and standard interfaces, the 
system studied includes a Small Computer System Interface (SCSI) for 
interfacing the WORM drive. The system itself is designed around the STD 
bus, using readily available boards. Configurations examined were (1) 
master processor board and slave processor board with the SCSI interface, 
(2) master processor with SCSI interface, (3) master processor with SCSI and 
Direct Memory Access (DMA), (4) master processor controlling a separate 
STD bus SCSI board, and (5) master processor controlling a separate STD bus 
SCSI board with DMA. 


Storage times for 512-byte disk sectors ranged from 56 to 22.5 milliseconds 
without DMA and 53 to 8.9 milliseconds with DMA. The faster times resulted 
from using large blocks of data per disk write request. With the faster times, 
the storage rates significantly exceed anticipated data acquisition rates. 
While DMA is especially attractive, configuring workable systems from 
available boards without hardware modification is difficult. 
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INTRODUCTION 


The success of manned space exploration depends in part on an 
understanding of the physiological effects of microgravity. A major 
concern of life sciences research in space is to guarantee the health and 

safety of astronauts for missions of both long and short duration. 
Additionally, astronauts have experienced many symptoms during exposure 
to microgravity. These latter symptoms have been subsumed under the 
rubric of "Space Adaptation Syndrome." It is part of the charter of the Life 
Sciences Flight Experiments Program (LSFEP) to perform experiments in 

space that will contribute to the understanding of the physiological effects 

of space travel on humans and, where possible, to develop strategies for 

reducing the debilitating effects. 


Most flight investigations require the use of a microcomputer for high 
speed collection, storage, and downlinking of in-flight physiological data. 
The Life Sciences Laboratory Equipment (LSLE) Microcomputer has served 
these needs for life sciences investigations in the shuttle Spacelab module. 
This computer has provided the link between Spacelab experiments and the 
Science Monitoring Area (SMA) in the Life Sciences Project Division 
building at the Johnson Space Center (JSC). To perform this function the 
LSLE microcomputer sends formatted real-time data, in a digital serial form, 
to a High Rate Multiplexer (HRM) in the Spacelab module, which in turn 
transmits the data to the ground via a Tracking and Data Relay Satellite 
System (TDRSS) satellite. 


While the old LSLE microcomputer has served its purposes well, it has 
become obsolescent and must be replaced by a newer design. Shortcomings 
of the old LSLE microcomputer include a lack of replacement units and parts, 
an absence of on-board mass storage or real-time data display, an inability to 
be programmed in a high level language, and poor general specifications 
when compared to today’s standards. Because of these deficiencies, the 
development of a new LSLE microcomputer is now a high priority item. The 
requirements for a replacement LSLE microcomputer include all of the data 
acquisition, HRM downlink, and experiment control functions of the 
current machine. Additionally, the new microcomputer must have better 
and more extensive displays, faster data sampling rates, extensive archival 
storage capabilities for use in middeck experiments where no HRM downlink 
is available, greater processing speed, more memory, compatibility with 
popular commercially available systems such as the IBM PC, and the ability 
to be programmed by the principal investigator using common high-level 
languages. The design should be based to the maximum extent possible on 
commercially available boards and should avoid custom hardware as much as 
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possible. It is hoped that the HRM interface is the only custom design 
required. 


A multiple processor system has several advantages over single processor 
systems. In the multiple processor system, one processor (called the 
"master") is reserved to the maximum extent possible for the principle 
investigator’s use, while additional processors (called "slaves") are dedicated 
to each input/output operation. For example, separate slave processors are 
used for analog to digital conversion (A/D), digital to analog conversion 
(D/A), Parallel I/O, Serial I/O, the HRM interface, optical disk control, etc. In 
this way, work is shared among the many processors. Once this partitioning 
is defined, separate engineering efforts can attack each task and 
development work can proceed in parallel. Expansion would have minimal 

impact on the original parts of the system, as additional processors would 
handle the additional data acquisition load. This modularization facilitates 

software and hardware maintenance. It allows on-going replacement of 
obsolete components at the board level, without significantly disturbing 
other parts of the system. A chief advantage of this concept is that the 
modular nature of the system extends into the hardware itself, thereby 
making development and reconfiguration much simpler. 


One of the most important elements of the new LSLE microcomputer is the 
optical disk. The Write Once Read Many (WORM) optical drive would allow 
the LSLE microcomputer to be used in the shuttle middeck where no 

downlink capabilities are available. This will allow the LSLE microcomputer 
to be used on a much larger number of flights (including those not flying 
the Spacelab), thereby greatly expanding opportunities for the Life 

Sciences Flight Experiments Program. In most cases, the investigator will 

prefer real-time data downlink, but as flight opportunities are limited, he 
may choose to fly his experiment in the middeck rather than to risk losing 

the opportunity altogether. In other cases, the investigator may be given a 
late opportunity to add his experiment to an existing fully developed 

payload. In this case, time may not permit the development of ground 

software to handle the HRM data stream. Again, the use of an optical disk 
will reduce data handling costs and development times. It has been 

estimated that the cost of ground software to handle the HRM data stream for 
life sciences experiments is $250,000 per mission, regardless of the number 
of experiments served. The use of the optical disk instead of the HRM would 
remove this cost entirely. In summary, the use of an optical disk will allow 
single experiments to be inserted into missions on relatively short notice 
and will permit full use of the middeck by life science investigators. Other 

bulk storage systems, such as streaming tape and other magnetic devices, do 
not offer the robustness and high data density of the optical disk. 


The objective of my work this summer was to develop prototype software 
needed to store collected data on an optical disk as well as to recover it. Also, 
timing studies were to be performed to determine if data storage rates would 
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be sufficient for the data collection sample frequency required of the new 
system. 


EQUIPMENT USED 


The commonly used STD bus was chosen for the system backplane. This bus 
is well supported, with several hundred manufacturers offering several 
thousand boards. Thus, prospects are excellent for future upgrades in 
keeping with advances in technology. 


The STD bus processor boards selected for the system are based on the Intel 
8088 and 80188 processors. Advantages of these boards include processor 
compatibility with the familiar IBM PC family and the availability of a wide 
range of software and hardware support products. In the system under 

study, the master processor board is the Ziatech Corporation ZT8815, 
containing an 8 MHz 80188. This board has computing power similar to the 
IBM PC/AT. Of particular interest, the 80188 processor chip contains Direct 
Memory Access (DMA), which provides fast memory -- peripheral data 
transfer in parallel with other processor functions. Additional processor 
boards, slave processors, are Ziatech ZT8830 boards. These contain 8 MHz 
8088 . processors, with computing power approximating that of the IBM PC. 

Both master and slave boards contain a standard SBX interface and connector 

for "piggyback" peripheral modules. Hundreds of modules are available 

from dozens of vendors, providing real-time input and output hardware. 
Thus self-contained data acquisition subsystems can be formed using, for 
example, an SBX analog to digital converter attached to a slave processor 
board. 


The optical disk interface is the Small Computer System Interface (SCSI) 
standard. One configuration uses a slave processor with the Zendex 
Corporation model ZBX-280 SCSI SBX module. The ZBX-280 is based on the NCR 
5380 SCSI controller chip. The same SBX module attached to the master 
processor is an alternative configuration, which allows the use of DMA, not 
available with the slave processor boards. Another alternative SCSI 
interface is the Ziatech STD bus peripheral board, the ZT8850, which 
provides a chip set for SCSI as well as other disk control devices. The ZT8850 
includes its own DMA. Compared to the Zendex ZBX-280, the ZT8850 is simpler 
to program, with more SCSI signals generated by hardware rather than 
under program control. The master processor board controls the ZT8850 as a 
bus peripheral, unlike the ZBX-280 which is directly interfaced and does not 
reside on the STD bus. With the ZT8815 processor and the ZT8850 SCSI boards, 
DMA may be implemented using either the 80188 DMA of the ZT8815, or the 
ZT8850 on-board DMA circuits. 
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The optical disk drive is the Optotech model 5984. This drive was selected 
because Mountain Optech (Boulder, CO) makes a space qualified version of 
the drive (model 200SES) under contract to Goddard Space Flight Center. The 
model 5984 is identical in electrical and software characteristics to the model 
200SES, but is less expensive. Both are 200 megabyte (per side) capacity 
optical disk drives, using 5 1/4 inch removable media cartridges. 


A summary of the equipment used and location of principal vendors is given 
in Table 1. 


SOFTWARE DEVELOPED 


Test programs were written to assure that the optical disk could be both 
written and read in the various configurations considered, and to determine 
read and write times. Best case conditions were used in that no other 
competing activity was required of the processor chip or, where used, the 
STD bus. In all cases, a main program in C calls a collection of assembly 
language functions. For support of the Zendex SCSI piggyback (NCR 5380 
chip) interface with either master or slave processor board, the assembly 
language routines are revisions of routines provided by Mountain Optech. 
Each principal SCSI phase is handled by a separate call: reset, selection 

(including arbitration), status, command, message in, data output, and data 
input. (The message out phase has not been implemented.) The data 
transfer is byte by byte, with polling and handshake signal generation by 
software. The calling program can thus check for proper progression of 
phases and handle error conditions. Additional functions were written for 
DMA use for the data input and data output phases with the Zendex SCSI 
interface used with the ZT8815 master processor board. 


A separate set of assembly language functions, matching the names and 
organization of the above routines, has been prepared for use with the 
master ZT8815 board and ZT8850 peripheral SCSI board. These require no 
significant change in the C calling programs written for other 
configurations. While the example code available from Ziatech for the 
ZT8850 support was influential, these routines followed the organization of 
the functions for the Zendex interface, rather than the task oriented Ziatech 
routines. The routines for the ZT8850 are generally simpler than those for 
the NCR 5380 based Zendex interface. The ZT8850 does not support 

arbitration. The handshake signals required for data transfer are hardware 
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TABLE 1. - EQUIPMENT USED. 


HARDWARE 

Ziatech 8862 Card Cage and Power Supply (STD bus) 

Ziatech ZT8830 Intelligent I/O Control Processor (slave) 

Ziatech ZT8815 80188 based CPU card (master) 

Zendex ZBX-H280 SCSI controller multimodule (iSBX) 

IBM PC compatible personal computer for downloading programs to STD bus 
boards 

Digital storage oscilloscope for obtaining timing data 
Mountain Optech Model 5984 Optical disk drive 


SOFTWARE 

Ziatech 8830 Debug software (and ROMs) to load and debug programs 

Ziatech 8815 Debug software 

Microsoft C Language, version 4.00 

Microsoft Macro Assembler, version 4.00 

Microsoft Linker (loader), version 3.51 

Microsoft MS-DOS operating system, version 3.10 (for program development) 


VENDORS 


Ziatech Corporation 
3433 Roberto Court 
San Luis Obispo, CA 
93401 

(805) 541-0488 


Zendex Corporation 
6700 Sierra Lane 
Dublin, CA 

94568 

(415) 828-3000 


Mountain Optech 
2830 Wilderness Place 
Suite F 
Boulder, CO 

80301 

(303) 444-2851 


Microsoft Corporation 
10700 Northrup Way 
Bellevue, WA 

98004 

(206) 882-8089 
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generated. The data transfer is still byte by byte, with handshake signal 
polling to avoid data loss. Some DMA support routines for the ZT8850 have 
been developed. 


Copies of software developed for this project may be obtained from Peter N. 
Bartram, Division of Engineering, Norwich University, Northfield, Vermont 
05663 (telephone 802/485-2263), or Donald. Stilwell, NASA/Johnson Space 
Center, Mail Code: SE3, Houston, Texas 77058 (telephone 713/483-7308). 


RESULTS 


Polled data transfer can be performed in all configurations studied (ZT8830 + 
ZBX280, ZT8815 + ZBX280, and ZT8815 + ZT8850). DMA writing to the optical 
disk may be performed using the ZT8815 with ZBX280 configuration, 
provided the SBX signal TDMA, not implemented by the ZT8815, is grounded 
(requiring the addition of a wire on either the ZT8815 or the ZBX280). The 
ZBX280 uses this signal for one alternative for ending DMA transfer. With it 
left floating, as on the ZT8815, the ZBX280 attempts to halt DMA prematurely. 
Even with this change, with which DMA writing to disk works well, DMA 
reading of the disk returns incorrect values. The source of difficulty has 

not been determined with confidence. The ZT8850 DMA controller functions 
correctly, provided the memory used is not on the ZT8815 processor card 
controlling it. (A separate memory board was used.) Also at the time of this 
writing, code for using the ZT8815 processor DMA with the ZT8850 is under 
preparation. 


For polled data transfers, timing results were similar for both reading and 
writing. For the LSLE replacement microcomputer, disk writing in real-time 
is critical, whereas reading will be performed at a later time, when speed is 
of lesser importance. With the ZBX280 SCSI interface, writing a single 512 
byte sector each call for data output, the average write time was less than 56 
milliseconds per block, regardless of processor. With each write request 
specifying a ten-sector block (5120 bytes), the average write time for ten 
sectors was 250.4 milliseconds (25.04 milliseconds per sector). Some ten 
sector blocks required 225 milliseconds, others 276 milliseconds. These 
times were identical for both the ZT8830 and ZT8815 processor boards. For 
write request block sizes of 25 sectors (12800 bytes), the average time 
required was 562.5 milliseconds per block (22.5 milliseconds per 512 byte 
sector). This is over 22 kilobytes per second. Since each real-time 
measurement results in a two-byte value, data storage in excess of 11000 
samples per second is possible. 
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For the ZT8850 SCSI with no DMA, write times for single sector requests 
averaged 52.7 milliseconds per sector. For ten sector blocks, the average 
time per block was 197 milliseconds (19.7 per 512 byte sector). With 25 sector 
blocks, the time averaged 369 milliseconds (14.8 milliseconds per 512 byte 
sector). With 25 sector (12800 byte) blocks, over 33.8 kilobytes per second 
can be stored, or over 16,900 measurement samples per second. 


With DMA using the ZT8815 with ZBX280, single sector write times averaged 
52.7 milliseconds per sector. For DMA using blocks of 10 sectors per write 
request, the write time per block fluctuated between 124 and 176 

milliseconds, averaging less than 150 milliseconds per block (15 
milliseconds per 512 byte sector). The time required to write blocks of 25 
sectors fluctuated between 210 and 260 milliseconds, averaging 221 
milliseconds per 12800 byte block, or 8.84 milliseconds per 512 byte sector. 
Thus with DMA, storage rates in excess of 56 kilobytes per second (28000 
measurement samples per second) are possible. 


Using the ZT8850 STD bus SCSI board with DMA (as provided on the ZT8850 
board), single sector write times also averaged 52.7 milliseconds per sector. 
Average write times using blocks of ten seconds per write request also was 
less than 150 milliseconds per block, 15 milliseconds per sector, and the same 
fluctuations in time were observed. However, the times for writing blocks of 
25 sectors were longer: fluctuating between 260 and 312 milliseconds, 

averaging about 269 milliseconds per block. With this, about 46.4 kilobytes 
per second average storage rate results. 


CONCLUSIONS AND RECOMMENDATIONS 


Without DMA, data storage rates are marginally adequate for anticipated data 
collection rates. With DMA, storage rates exceed any envisioned 
requirements. DMA is particularly attractive because during data transfer 
to the disk, the processor is freed for other tasks. 


At this point, it appears better to use the master processor for control of the 
SCSI interface to the optical disk. At the time of this writing, no slave 

processor supporting DMA is available with an SBX piggyback connector 
(for an SCSI interface), though these are under development. In order to 
gain the benefits of DMA, the master must be used to control the SCSI 
interface. Even if the slower transfer rates of currently available slave 
processor boards supporting the SBX piggyback modules (such as the ZBX- 
280 SCSI) are accepted, significant master processor usage would still be 
involved. This is because one slave cannot access memory of others. Thus 
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the master would have to transfer data from data acquisition slaves to the 
SCSI slave memory. With the master controlling the SCSI interface, no 
memory to memory copy is required. The master can send data to the SCSI 
directly from data acquisition slave board memory. 


Block size is the most important factor for write speed. This is probably 
because with large numbers of contiguous sectors written with one write 
command, fewer disk seeks are required to properly position the write 
heads. DMA only marginally improved single sector block write times, 
where seek time seems to be limiting. With larger block sizes, not only is 
speed improved with both methods, but DMA gives markedly improved 
performance. With large amounts of data being written with each output 
command, data transfer time becomes limiting, as the number of seeks is 
reduced. The uneven write times can probably be attributed to the 
occasional write head repositioning required for two contiguously addressed 
sectors located on adjacent disk tracks. 


However, DMA is not without difficulty, especially in mixed-vendor 
configurations. The TDMA signal incompatibility has been mentioned 
earlier. It is suspected that other problems of non-standard standards may 
be involved in using DMA in other configurations. The system designer 

must have a good understanding of both hardware and systems 
programming. 


Several recommendations now can be made. (1) Further work is needed to 
test alternative DMA configurations. (2) As the block sizes were here chosen 
arbitrarily, optimization of the number of sectors written per write request 
in light of memory requirements is required. Along with this, the need to 
interleave data from several data acquisition slaves needs to be considered in 
determining block size. (3) It is important that the timing studies be 
repeated in a prototype system with all parts functioning. With other 
activity on the STD bus and more demands on the master processor, it should 
be verified that data storage rates will be maintained at a level exceeding the 
requirements of the data acquisition slave processors. (4) When slave 
processor boards supporting DMA and the SBX piggyback modules become 
available, the wisdom of placing the SCSI under control of the master 
processor should be reconsidered. 
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